The present invention relates to apparatus and methods for building compatibility between different computer systems and, more particularly, but not exclusively to methods of data export and import between such incompatible systems.
There are several global industries in which different parties in the industry must transfer information to one another. It is often the case that these parties use different IT systems, which are not designed to communicate with one another. These systems lack a usable interface and/or connectivity capabilities.
An additional and, probably, the most problematic issue is incompatible business rules of the source and target systems. Often this is the main obstacle in connecting systems, even when both parties support an agreed data-transfer protocol.
As a result, at many stages of the process, data must be manually re-keyed, reformulated, revalidated, or manipulated multiple times so that it can be processed by a variety of incompatible systems. The complexity, redundancy, and manual nature of the process mean that errors may occur at multiple points, resulting in high costs and slow turnaround times.
Moreover some data elements are not available and are needed to be retrieved from different sources to be entered again for completing the process.
There are currently two possible solutions to these difficulties. The first is to build a special purpose interface and/or to undergo integration projects, in order to modify the existing systems so that the systems are capable of communicating with each other. This approach has the following disadvantages:                1. Integration projects between different systems are generally very expensive and time consuming, and require substantial cooperation from the different parties involved.        2. Additionally, the result is tailored to specific systems. Adding a new system, or changing one of the existing systems, generally requires changing the communication interface, or performing additional modifications of the systems, in order to accommodate the new conditions.        3. The source and target systems become dependant on each other. Changes to either one of the systems may impact the interface.        
The second method currently in use for resolving communication difficulties between systems is to define a communication standard. Systems complying with the standard are able to communicate with other systems employing this standard. This approach has the following disadvantages:                1. Designing and maintaining a standard that will cover the continuously evolving needs of all industry members is a long and expensive process, requiring participation and support of all members.        2. Adopting a new standard is ineffective unless all the different systems support the adopted standard. For industries that are very diverse, achieving a unified standard is almost impossible.        3. Changing existing systems to comply with a new standard is very difficult. The changes required for each proprietary system are generally expensive and time consuming, especially for legacy applications.        
None of the above approaches however, solves the problem of different business rules that are used by the source and target systems. Even if the systems are integrated and/or support a mutual communication standard, valid information from the source system may be deemed invalid and unacceptable by the target system.
The Insurance Industry
The insurance industry is an example of an industry which suffers from inefficiency due to incompatible data formats and greatly varying business rules of existing systems. For many years insurance companies have been providing the ability of entering data and performing transactions via terminal connection. In recent years many companies have moved to modern technology, using agents' portal web sites. However, this technological progress has not solved some intrinsic difficulties of agent-to-carrier communication:                Any information flow, such as quote calculation, policy submissions, endorsements, and policy information inquiries, requires entering the same information into several different systems. Even if the information was previously entered into the agency management system, the agent needs to reenter the information into the carrier's system, which is typically done either through a terminal or at the carrier's web site.        The information flow includes going to third party data providers to enter and fetch information such as a credit score, which is then entered into yet another system.        If a number of carriers participate in the process, for instance if the agent wishes to obtain multiple insurance quotes, the problem's complexity is multiplied.        
The insurance industry in the U.S. has created standard formats for collecting and transferring data through ACORD (the Association for Cooperative Operations Research and Development). However, adoption of the ACORN standard                Requires making changes to existing systems,        Enables communication only between the parties that have adopted the standard, and perhaps more importantly,        Does not solve the problem of incompatible business rules.        
Why is Incompatible-Business-Rules a Hard-to-Solve Problem?
The most basic requirement of automated communication is proper transformation of the data. Even if some of the information is incompatible with the business rules of the target system, no data loss should occur, and the user should be given an opportunity to fix the original values to comply with these rules. The method of receiving the data from a source system, such as Agency management system, storing it and allowing a user to fix the data to comply with the business rules of the target system raises the following difficulties:
Problem 1: Storing the Data
Insurance carriers internal applications use proprietary data models that are designed to store only the data that is compliant with the carrier's business rules. For example, if in the carrier's system the field “limit” can receive the values “500,000” and “1,000,000”, the system will either not handle or will need to be changed to support a required input value “700,000” from a source system.
Problem 2: Changing the Application
The existing applications are designed to receive information stage by stage, every time validating the data that has been gathered so far. The screens are designed to appear empty or with information compliant to the business rules. This means both application workflow and data entry screens need to be redesigned to support data import from source systems.
In the example referred to above, the upgraded system, cannot present a screen with an empty value for the limit, since this would constitute loss of information. Nevertheless it cannot enter the value since the target system will not accept it.
Both problems become even harder to solve, when the differences between ACORD XML and the carrier's data model are in the structure or hierarchy of the information. For example, the carrier's system might support only policy-level coverage, while in the agency management systems and ACORD XML coverage might be in respect of location or vehicle level. Since the data cannot be automatically mapped into a policy-level only model, the carrier's database and application would have to be expanded to accommodate any possible ACORD XML.
However, insurance industry members are often reluctant to make significant changes to their existing systems, due to                The high costs of such projects.        Questionable return on investment (ROI) and usability of the upgraded system.        Long implementation and integration periods and the retraining required to company employees and users.        
There is thus a widely recognized need for, and it would be highly advantageous to have, an interfacing system devoid of the above limitations.